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REMARKS 

Claims 1-10 are currently pending in the application. By this amendment, claims 1 and 5 
are amended. Claims 9 and 10 are newly added for consideration. Support for the amendment 
and can be found at least at page 8, lines 2-5. Support for the newly added claims can be found at 
least at page 3, lines 23-25. Reconsideration of the rejected claims in view of the above 
amendments and the following remarks is respectfully requested. 

Objection to Drawings 

The drawings were objected to for having lines, numbers and letters not uniformly thick 
and well defined, clean, durable and black (poor line quality). In response, Applicant submits, 
herewith, amended Figures 1 and 2 with lines and letters uniformly thick and well defined. 

35 U.S.C. §103 Rejection 

Claims 1-2 and 5-6 were rejected under 35 U.S.C. § 103(a) for being unpatentable over 
U. S. Patent No. 5,644,719 issued to Aridas, et al ("Aridas") in view of U. S. Patent No. 
5,878,225 issued to Bilansky, et al ("Bilansky"). Claims 3-4 and 7-8 were rejected under 35 
U.S.C. §103(a) for being unpatentable over U. S. Patent No. 5,644,719 issued to Aridas, et al in 
view of U. S. Patent No. 5,802,278 issued to Isfield et a/.("Isfield") These rejections are 
respectfully traversed. 

The present invention is directed to a lightweight, stackless, method and system to 
provide inter process communication (IPC) between processors in a network. Software enabled 
functions provide for opening and closing inter process communication paths for transmitting 
and receiving communication frames in the network environment. The software functions may 
select either data or control paths to transmit or receive the frames. The invention provides light- 
weight IPC protocol and does not require a stack on each processor to accomplish the IPC. In 
previous methods, layers of software stacks were employed to enable IPC communication 
between processors in a network environment. These stacks are expensive and require additional 
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management. The present invention also provides headers in communication frames to exchange 
various frame formats. 

Claim 1 has been amended to include, in part, 

a) providing software enabled functions that open and close inter 
process communication paths for transmitting and receiving of inter 
process communication frames; 

b) providing software enabled functions that allow said inter process 
communication frames to be stacklessly transmitted to one or several 
processors in said network processing environment; (Emphasis added) 



Claim 5 has been amended to include, in part, 

a) software enabled functions that open and close inter process 
communication paths for transmitting and receiving of inter process 
communication frames; 

b) software enabled functions that allow said inter process communication 
frames to be stacklessly transmitted to one or several processors in said 
network processing environment; (Emphasis added) 



In order to reject a claim under 35 U.S.C. §103(a), MPEP 2143, states, in part: 

"To establish a prima facie case of obviousness,... there must be 
some suggestion or motivation, either in the references themselves or in 
knowledge generally available to one of ordinary skill in the art, to modify 
the reference or to combine the reference teachings.... Finally, the prior art 
reference (or references when combined) must teach or suggest all of the 
claimed limitations." 
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In the present combination suggested by the Examiner, however, there is no motivation to 
combine, nor is there any teaching or suggestion that the combination of references show all the 
claimed limitations. 

Aridas 

Aridas is directed to a network of computers having an EPC structure between application 
processes and underlying intracomputer and intercomputer message transport mechanisms (col. 
2, 11. 24-28 and col. 2, 1. 66 - col. 3, 1. 3). The IPC includes a REGISTER function to send or 
receive messages by registering a name and PID. A SEND function is used to send a message 
using the underlying transport mechanisms. A RECEIVE function links to the underlying 
transport mechanism of the recipient's host so that the recipient receives the messages addressed 
to it. As can be readily seen, the Aridas invention creates an IPC arrangement by layering on top 
of existing transport mechanisms as shown in Figures 2 and 3. The IPC (70, 71, 72) interfaces 
with the Intra-computer communication facility 35, the Inter-computer communication facility 
36, and the intercomputer communication facility 37. As shown in Figure 3, item 37 includes 
SCSI stacks, item 36 includes WAN stacks, and item 35 includes UNIX layers for intracomputer 
communication. At col. 3, 11. 43-49, Aridas states that the computers 1 1 are intercoupled through 
a WAN using, for example, TCP/IP communication interface. It is quite apparent that Aridas is 
employing conventional communication layers (stacks) to provide functionality. This causes 
added overhead which the present invention avoids, as stated at least at page 8, 11. 2-5, 

This invention enables information exchange between processors in a network 
processing environment without requiring an IP stack on each General Purpose 
Processor and not requiring additional overhead. 
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Further, Aridas states (col. 3, line 42-43) that the system of Figure 1 is that described in U.S. 
Patent No. 5,579,371. A review of this patent shows a system replete with SS7 and Common 
Channel signaling layers (i.e., stacks). Aridas is providing software functions layered on existing 
stacks. 

The invention, on the other hand, provides a lightweight IPC protocol (see page 2, lines 
2-5 and page 4, lines 10-12) by providing software functions that manages data frames and 
guided control frames directly via APIs (page 3, line 26 - age 4, line 10.) As can be seen in the 
description of user_rcvIPC_func (page 5, lines 12-24) includes a pointer to Rbuf which is the 
Raw buffer which contains the received frame. The length of the data frame and the address of 
the start of the frame must be sent in the Raw buffer. Also, Rbuf is employed in 
np_ts_sndIPC_unicast for sending an IPC frame (page 6, line 12- page 13, line 2) and in 
np_ts_sndIPC_multicast for sending a frame in multicast mode (page 7, lines 8-21). The 
present invention controls the reception and transmission of frames directly via the Raw buffers 
and does not employ any stacks as does Aridas. This provides the lightweight aspect of the 
current invention. 

Bilansky 

Bilansky is directed to a method and system for communicating data and control 
information between two systems, each system includes a communication stack (Summary). 
Software modules include OPEN, GET, PUT, UPDATE, RELEASE, DELETE, CLOSE, and 
OPC. These modules provide an interface to handle control through an APPC protocol stack, and 
alternatively, through a fast-path feature. It is clear that Bilansky employs stacks in the APPC 
mode (Abstract and Summary). In the fast-path mode, bypassed are: ICF (103, 113), advanced 
peer-to-peer communication function manger (APPC FM) 104, 1 14, data flow control 107, 117, 
data control layer 108, 1 18, and line driver 109, 1 19 on both source and target sides for all GET 
and PUT operations (col. 6, lines 39-45.) However, what remains (i.e., not by-passed) is IPCF 
(121) and IOP (123) of Fig. 2 which are the interprocess communication facility (col. 6, line 1). 
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It appears then that the fast-path does indeed employ at least one stack (i.e., the interprocess 
communication facility). 

Since neither Aridas nor Biliansky teach all of the features of claim 1 and 5, nor is there 
any suggestion to combine the teachings of Aridas with Bilansky in the references themselves, 
Applicant submits that claims 1 and 5 are drawn to allowable subject matter. 

Since claims 2 and 6 are dependent claims from independent claims 1 and 5, respectively, 
Applicant submits they are also allowable. Accordingly, Applicant respectfully requests that the 
35 U.S.C. §103(a) rejection over claims 1-2 and 5-6 be withdrawn. 

Isfeld 

Isfeld is directed to a high performance scalable networking bridge/router system for 
interconnecting a plurality of networks including an internet protocol (IP). Isfeld does not teach 
or suggest the use of "stackless" IPC communication. Applicant submits that Isfeld does not 
supply the missing feature of Aridas and Bilansky. Since claims 3-4 and 7-8 depend from 
independent claims 1 and 5, respectively, Applicant respectfully submits that claims 3-4 and 7-8 
are allowable based at least on their dependency from allowable claims 1 and 5, respectively. 
Applicant therefore respectfully requests that the 35 U.S.C. §103(a) rejections of claims 3-4 and 
7-8 be withdrawn. 

CONCLUSION 

In view of the foregoing amendments and remarks, Applicant submits that all of the 
claims are patentably distinct from the prior art of record and are in condition for allowance. The 
Examiner is respectfully requested to pass the above application to issue. The Examiner is 
invited to contact the undersigned at the telephone number listed below, if needed. Applicant 
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hereby makes a written conditional petition for extension of time, if required. Please charge any 
deficiencies in fees and credit any overpayment of fees to IBM's Deposit Account No. 09-0464. 



McGuire Woods, LLP 

Suite 1800 

1750 Tysons Blvd. 

McLean, VA 22102 

(703)712-5341 



Respectfully submitted, 



Charles J. Grass 
Registration No. 52, 972 




Andrew M. Calderon 
Registration No. 38,093 
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